%#### TOBIAS #####
\section{Feedback loops}
%Feedback loops
Within a feedback model even loops between two components can appear.
For example take a look at the figure below, where the relationship between weight, exercise and the frequency of lower back crisis is shown.
The darker path shows the relationship of growing back problems leading to decrease exercises and doing less exercise will additionally increase back problems.
\begin{figure}[H]
\begin{center}
\pgfimage[width=0.6\textheight]{Grafiken/feedback_loops}
\end{center}
\caption[Feedback Loop]{Feedback Loop}
\end{figure}
 
This positive feedback loop can also be named as a vicious circle (german: \textit{Teufelskreis}), this complex of events will reinforce itself. In other words, each iteration of the cycle will reinforce the first event.\\

\newpage
\section{Feedback effects}

%Misinterpreation of model
%Reversibility & causation fallacy

\subsection{Reversible Fallacy}
\begin{center}
\textit{"What is done can always be undone."}
\end{center}

This misconception makes managers believe that they can always revoke previous actions.\\
But is it possible to fire half of your employees and hire them back the next
day? Or if you lift a rock and get a pain in the back, will it go away if you drop the rock?\\
The results aren't reversible that way. You can't go back to start and roll the dice again. Your back pain will stay and even most of your employees will stay away. The dice have fallen, and what is done cannot always be undone.

\subsection{Causation Fallacy}
\begin{center}
\textit{"Every effect has a cause... and we can tell which is which."}
\end{center}

The causation fallacy is strongly linked to feedback loops.\\
We like to know what is the effect and what is its cause.
Let us go back to our feedback loop example.\\
If you gain weight your back problems will increase, which decrease the amount of exercise, which will increase weight.
That means in the end, weight will increase weight.
But does gaining weight cause back problems, or do back problems cause gaining weight?\\
So far, so confusing. With a loop like that, we are not able to tell what is the effect and what is its cause.\\

\subsection{Explosion and Collapse}
These two runaway conditions will be produced by positive feedback. They only differ depending on the way you name the variables you are measuring.\\
Regarding our feedback model: weight will explode, exercise will collapse and work lost to back problems will explode.\\
Of course nothing can grow infinitely, but if you reach one hundred percent lost work time, a threshold will be crossed and our system (feedback model) will "break". In order to that the old model will no longer apply. If you miss one hundred percent of your work, because of back pain, you may lose your job. And even worse, the collapse may lead you to have a back surgery. Whatever it takes you will never be the same as you were before you started on this runaway path.\\ %TODO: das ist doch fast wörtlich kopiert oder?
%NOTES:
%exercise-weight example on p.91
%explosion and collapse are both runaway conditions
%if work lost over 100\%, the system will "`break"'; something so big will happen, that the old model will no longer apply
\subsection{Brooks's Law}
\begin{center}
\textit{"Adding manpower to a late software project makes it later."}
\end{center}

\begin{figure}[H]
\begin{center}
\pgfimage[width=0.6\textheight]{Grafiken/brooksLaw}
\end{center}
\caption[Brooks's law]{Brooks's law}\label{Brooks Law}
\end{figure}

Brooks's Law is a principle in software development. There are two main factors:
\begin{enumerate}
\item Software projects are complex systems and new workers take some time before they get productive. First they must become educated about the work and this education requires resources already working on the project. That process decreases the all over productivity. And what is sometimes even more worse, is a higher failure rate in coding of the new workers that are not that familiar with the code base.
\item Communication overhead increases with the number of people. To keep every worker on the same task synchronized, the communication channels increase along with the square of the number of people. So as more people are added, the more they spend time trying to find out what everyone else is doing.
\end{enumerate}
The effect of Brooks's Law can even be made worse by management action. The thick arrow in figure \ref{Brooks Law} illustrates where the typical error occurs: By adding new people to the project, that are decreasing the productivity due to their lack of knowledge instead of raising it.\\ But management decision can also avoid Brooks's Law, we will come back to that in chapter \ref{failing_to_steer}.\\

\subsection{Act early, act small}
% page 92ff
%Act early, act small
Often managers believe their non-linear system will fix itself, but they are wrong. One reason management action contributes into a runaway condition is the tendency to respond too late to deviations. Their following correction is often too big, which themselves have non-linear consequences and create a huge positive feedback loop. The project will not only be too late, it will collapse! That's why it is necessary to act early and small.\\
%NOTES:
%managers believe their nonlinear system will fix itself
%following correcting is too big; hugh positive feedback loop; project is not only late, it will collapse

\subsection{Negative Feedback Loop}
% page 94ff
With all these positive feedback loops our system is going to be unstable, it may not collapse now, but it is only a question of time.
When you analyze a software development organization, one of the first things to look for are positive feedback loops - disasters are waiting to happen.
Unless these unstable systems are stabilized in some way, all other management actions are only touching the surface. For example throwing lots of overtime hours into testing a system full of bugs may delay the disaster for a short-time. Perhaps you will get a shippable product, but this action will sooner or later lead to a irreversible system collapse. But why doesn't everything collapse?\\

The only mechanism that has the power and speed to prevent runaway due to positive feedback loops in a system are other feedback loops. These stabilizing loops, in a living system are often hundreds of such actions, are called \textit{negative feedback loops} or deviation-reducing loops.\\

If we return to our back problem example, a negative loop might be to regulate the amount of eating. With increasing back problems, you have to decrease your eating, that will decrease your weight and result in fewer back problems.\\

\begin{figure}[H]
\begin{center}
\pgfimage[width=0.6\textheight]{Grafiken/negative_feedback_loop}
\end{center}
\caption[Negative Feedback Loop]{Negative Feedback Loop}
\end{figure}

Within a software project a positive feedback loop might be lots of overtime, while a negative feedback loop could be doing technical reviews.\\

For a manager in a software development system there are two major negative feedback loops to exercise control: one involving resources and one involving requirements. %TODO nocch nen bisschen ausführen

%%Negative Feedback - why everything doesn't collapse
%\begin{center}\pgfimage{Grafiken/pfeilNegOhneSchrift}\end{center}
%
%	\begin{itemize}
%		\item Stabilizing loop / deviation\footnote{deviation - Abweichung}-reducing process
%		\item<2> Involve resources and/or requirements
%	\end{itemize}
%
%
%
%NOTES:
%positive feedbacks loops make model unstable; if systems stay unstable, all other management actions are only cosmetic\\
%ex.: lots of overtime = pos. feedback loops; technical reviews = neg. loops\\
%ex. for neg. loop: more errors could lead to more resources devoted to technical reviews (p.96)\\
%pattern 3: two major ne. feedback loops with which to exercise control: one involving resources and one involving requirements\\

\newpage


\section{Steering Software}
%Waterfall model
% page 100ff
Measurements based on accurate diagrams of effects or models will support you in making more successful predictions of how the system will behave by itself. But in order to steer, you also need models of how your intervention will affect the system.\\
A typical methodology prescribes an ideal series steps that will take your project from beginning to end, like the sequential Waterfall Process Model. Sequential methodologies for software development have some common assumptions:
\begin{enumerate}
\item There will be no mistakes
\item If there happen to be mistakes, they will be little ones
\item The responsible parties will certainly know how to correct such little mistakes
\end{enumerate}

Sequential methodologies are essential linear processes and small linear corrections can be done be reasonable people.
But be aware that project's input has his own randomness, therefore your plans often won't be followed exactly.
And with a growing complexity of a project there is a need for explicit models of controller interventions.\\

%page 104ff
One important extension for system models is to add small feedback loops to the methodology.
Therefore you have to split a larger process into basic unit cells and each cell has feedback coming in from later cells and going back to earlier cells.\\
Another approach can be to split your large project into smaller micro-projects, so feedback cycles cannot grow too big. Feedback can move from one micro-project to another.\\
This feedback idea should be applied at different levels, not only at product level. A better idea is to go at process level or up to the cultural level.
%The same control model is needed at all levels and with it, people acquire the ability to think and observe in terms of non-linear effects and then act in concordance with those observations and thoughts. 

\subsection{Steer - Human decision points} \label{hdp}

Good intervention models will help us to understand what we can't control and where we can intervene.
Human decision points in our model are the places where we have a chance to prevent a crisis.\\
If you look at our previous example of Brooks's law (figure \ref{Brooks Law}) you
may find different spots where you, as a manager, will have the opportunity to intervene. It might be a
positive or negative point to intervene, or it will depend on your decision
whether it will have a positive or negative effect. All three types of human
decision points are visualized in figure \ref{brookhdp}.\\
The white square stands for a management action with a positive effect, while
the black square will have a negative effect. The half-half square stands for a
management action with an open choice of effect.\\

\begin{figure}[H]
\begin{center}
\pgfimage[width=0.6\textheight]{Grafiken/brooksLawMgmt}
\end{center}
\caption[Brooks's Law: Human Decision Points]{Brooks's Law:
Human Decision Points}\label{brookhdp}
\end{figure}

\begin{center}
\textit{"Whenever there's a human decision point in the system, it's not the
event that determines the next event, but someone's reaction to that event."}
\end{center}



%
%%\begin{center}\pgfimage{Grafiken/managementArrowsOhneSchrift}\end{center}
%%(methodologies)
%%Steer - Human decision points
%%        Notation & Example
%
%	\begin{itemize}
%		\item Models help us to understand what we can control
%		\item Models of how your intervention will affect the system
%		\item Adding feedback
%		\item Keep feedback early and small
%	\end{itemize}
%	
%	
%\textit{It's not the event that counts, it's your reaction to the event.}
%	
%NOTES:
%feedback over all levels; to become a culture\\
%same control model is needed at all levels (p.107)\\
%Whenever there's a human decision point in the system, it's not the event	that determines the next event, but someone's reation to that event.\\
%


\subsection{Intervention Model}
%        Quote:  p.111
%        p.110 n.1-4
%        diagram

A typical intervention model says something like this:\\
\textit{If the system is in state \textbf{B} and I do \textbf{X},	then \textbf{Y} will happen, which I hope is closer to state \textbf{G}.}\\

In a software context it would be something like:\\
\textit{If the program design is finished (state \textbf{B}) and we do the coding (\textbf{X}),	then we will be in the testing state (\textbf{Y}), which I hope is closer to state \textbf{G}.}\\

To manage a software project and consider an intervention to control something, you have to answer the following questions:
\begin{enumerate}
	\item (B\footnote{B = bad state}) What is the state of the system now?
	\item (X) What is the action I intend to take?
	\item (Y) What will be the dynamic of a system in state B if I take action X?
	\item Is Y closer to G\footnote{G = good state}?
\end{enumerate}
These questions will help you to find invisible states that might avoid your
interventions of being effective.\\

Managing to avoid a crisis consists of recognizing, maintaining, sustaining and
creating stabilizing feedback loops. Also recognizing, negating and decoupling
positive feedback loops is very important to prevent a collapse. Only by
modeling your interventions can you prevent adding new positive feedback loops
while solving problems.

\newpage

\section{Failing to steer}\label{failing_to_steer} 
\subsection{Scenarios}

\subsubsection{I'm just a victim}
%        victim & no control over the destiny of the project
%                p118-119 brooks law

Managers often think they have no control over the destiny of the project, they fail to steer well because they believe they are victims.\\
These managers use a typical "victim language" for their excuses.\\
\textit{"The project is behind schedule, and I can't do anything because Brooks's Law say I can't add people without making the project fall further behind."}\\

What can be done by a manager to \textbf{control} a project?\\ 
First of all, look at the human decision points in your model.\\
In a late software project new workers won't be dangerous. You, as a manager, can decide where they are going to work. These newcomers can be assigned to
\begin{itemize}
	\item review designs and code
	\item update the project documentation
	\item create test cases
	\item do the preliminary work for the other workers
\end{itemize}

You can also decide about the communication channels and responsibilities for your employees.
That means as a manager you are in the position to create your own laws and weaken or even avoid Brooks's Law.\\



%	\begin{itemize}
%		\item "`I can't do anything."'
%		\item Brooks Law + human decision points
%		\item Change from victim to controller
%	\end{itemize}
%
%
%NOTES:\\
%managers think they have no control over the destiny of the project\\
%ex. how to dodge Brooks Law and add people late to a project without disturbing others (p.118)\\


\subsubsection{I don't want to hear any of that negative talk}
%  negative talk & people are afraid to accept (talk about) bad news

Control actions can only be effective if they are based on accurate observations. Accurate observation results from conscious management decision.\\
What is necessary for accurate observation is trust.
If your project gets in trouble you will need very accurate reports what went wrong and why. Your employees have to trust you and don't be afraid of any punishment.
Afraid programmers for example are grouping a lot of failures under titles like "customer misreading documentation" or "operating system glitch". These categories directed attention away from the responsible employees and from the real problems. This misleading reports could not be used for any intelligent intervention.\\
To prevent this behavior managers can reward the messenger of accurate
reports. This will create a stabilizing negative feedback loop. Even management training for project leaders with special regard to communication skills can help to reduce the natural fear of telling bad news.\\
\textit{Trust takes years to build, but it can be destroyed in a minute.}\\


%	\begin{itemize}
%		\item Don't punish the messenger
%		\item Bad news = Good news
%		\item Necessary to make effective interventions
%	\end{itemize}
%	
%
%NOTES: punishment avoids negative talk; no accurate feedback; no possibility to react\\



\subsubsection{I thought I was doing the right thing}
% doing the right thing  - driving to destruction while thinking they help the situation

When managers think they are doing the right thing, they are often acting on
wrong intervention models. Thus makes it even more worse. Instead of doing the right thing, they do the exact opposite.\\
Based on faulty models they drive towards destruction while thinking they help the situation.
This boomerang phenomenon was a theme of Greek drama:\\
Oedipus' father tried to avoid his prophesied death; yet his actions led to his death. Oedipus desired to see the truth, so his actions made him blind.\\

To avoid such a situation a diagram of effects can be helpful to identify situations where managers are driving a project to destruction. 

%	\begin{itemize}
%		\item Believe in doing it right
%		\item Backward
%		\item Driving to destruction while thinking they help the situation
%	\end{itemize}
%
%
%NOTES: \\
%instead of doing it right, they do wrong; and worse than that, they do backward\\
%no real victim dynamic, but based on false models of how sth. really works p.123\\
%boomerang effect: ex. Oedipus' father tried to avoid his prophesied death; yet his actions led to his death.\\

